Checkout Standard Capabilities #15671
Conversation
justinkaseman
requested review from
pavel-raykov
and removed request for
pavel-raykov
justinkaseman
added
build-publish
justinkaseman
force-pushed
the
CAPPL-54
branch
8 times, most recently
from
a9eec4d to
87559f9
Compare
AER Report: CI Core ran successfully ✅AER Report: Operator UI CI ran successfully ✅ |
justinkaseman
force-pushed
the
CAPPL-54
branch
6 times, most recently
from
132d149 to
ca00b4f
Compare
justinkaseman
force-pushed
the
CAPPL-54
branch
from
ca00b4f to
b13d1e3
Compare
justinkaseman
added
build-publish
justinkaseman
force-pushed
the
CAPPL-54
branch
8 times, most recently
from
e8aa15c to
5d377da
Compare
| build_standard_capabilities() { | ||
| cd ./capabilities | ||
| npx [email protected] init | ||
| ./nx run-many -t build |
There was a problem hiding this comment.
@HenryNguyen5 @chainchad should I be using actions/cache to cache these binaries?
There was a problem hiding this comment.
Also no manifest right now. Is a manifest necessary for phase 1? Or can it come with phase 2 as we harden?
There was a problem hiding this comment.
The setup-go action should already cache the intermediate artifacts to the binaries, if not the binaries themselves. Probably best to leave it as-is. If build times continue to be an issue, it's better to publish the binaries on the capabilities repo side then pull down the pre-built binaries in here.
There was a problem hiding this comment.
WDYM by manifest?
Originally @chainchad @cedric-cordenier and I talked about the first iteration of this having:
"
Some manifest file which has the plugin name, version, url, and checksum. For ex.
version: 1.0
dependencies:
- name: dependency1
version: 1.2.3
url: [https://example.com/dependency1/v1.2.3/dependency1.tar.gz](https://www.google.com/url?q=https://example.com/dependency1/v1.2.3/dependency1.tar.gz&sa=D&source=docs&ust=1734635936940744&usg=AOvVaw16wDn9XzQdSKoTtxHG6Po1)
checksum: sha256:abcdef1234567890abcdef1234567890abcdef1234567890abcdef1234567890
"
But currently it just builds from the latest head in the capabilities repo without doing any checks
There was a problem hiding this comment.
got it, makes sense. Ill leave this up to @chainchad
There was a problem hiding this comment.
If we don't have a manifest, the implication is that we'll always build this with the latest standard capabilities? I suppose that's fine for this image which is a "develop" image. If we want to release this, I suppose we'll need that manifest then. Would that work?
There was a problem hiding this comment.
If we don't have a manifest, the implication is that we'll always build this with the latest standard capabilities? I suppose that's fine for this image which is a "develop" image. If we want to release this, I suppose we'll need that manifest then. Would that work?
Yes. That plan sounds good to me.
justinkaseman
changed the title
justinkaseman
force-pushed
the
CAPPL-54
branch
2 times, most recently
from
8d39792 to
229ef44
Compare
justinkaseman
force-pushed
the
CAPPL-54
branch
from
229ef44 to
e75054b
Compare
| build_standard_capabilities() { | ||
| cd ./capabilities | ||
| npx [email protected] init | ||
| ./nx run-many -t build |
| build_standard_capabilities() { | ||
| cd ./capabilities | ||
| npx [email protected] init | ||
| ./nx run-many -t build |
There was a problem hiding this comment.
The setup-go action should already cache the intermediate artifacts to the binaries, if not the binaries themselves. Probably best to leave it as-is. If build times continue to be an issue, it's better to publish the binaries on the capabilities repo side then pull down the pre-built binaries in here.
|
| aws-role-arn: ${{ secrets.AWS_OIDC_GLOBAL_READ_ONLY_TOKEN_ISSUER_ROLE_ARN }} | ||
| aws-lambda-url: ${{ secrets.AWS_INFRA_RELENG_TOKEN_ISSUER_LAMBDA_URL }} | ||
| aws-region: ${{ secrets.AWS_REGION }} | ||
| set-git-config: "true" |
There was a problem hiding this comment.
| set-git-config: "true" |
I think we can remove this since you're using the token explicitly in the next step?
| @@ -13,6 +13,7 @@ before_hook() { | |||
| install_local_plugins | |||
| install_remote_plugins | |||
| mkdir -p "$lib_path/plugins" | |||
| build_standard_capabilities | |||
There was a problem hiding this comment.
Do we want to always include these plugins going forward versus making it optional? If so, this makes sense.
| build_standard_capabilities() { | ||
| cd ./capabilities | ||
| npx [email protected] init | ||
| ./nx run-many -t build |
There was a problem hiding this comment.
If we don't have a manifest, the implication is that we'll always build this with the latest standard capabilities? I suppose that's fine for this image which is a "develop" image. If we want to release this, I suppose we'll need that manifest then. Would that work?
No description provided.